Week 2, Day 3 — Conditional Access policies

Day 2 review & the limitation of per-user MFA

• Quick check: "What is the difference between MFA Enabled and MFA Enforced? What happens when a user is Enabled but not yet registered?"
• Ask: "Right now, every Lakeview Logistics user is required to use MFA every time they sign in — even from a trusted corporate device on the office network. Is that the right balance?" — surface the bluntness of per-user MFA
• Ask: "What if a user is signing in from a country Lakeview Logistics doesn't operate in at 3am? Should that be treated the same as a sign-in from the office at 9am?" — prime the conditions concept
• Frame the day: Conditional Access replaces the blunt per-user MFA switch with a policy engine — MFA and other controls applied based on who, what, where, and how risky the sign-in is

The Conditional Access policy model — conditions, controls, sessions

Conditional Access is the most powerful identity security tool in M365. It is also the easiest to misconfigure in ways that lock users out or leave gaps. Students need to understand the model deeply before building policies.

• The policy model — If / Then — every CA policy is an If/Then statement: If a sign-in matches these conditions, Then apply these controls. The conditions define who the policy targets and what circumstances trigger it. The controls define what the user must do or what access they get.
• Conditions (the "If"):

• Controls (the "Then"):

• Report-only mode — always start here — every new CA policy should be deployed in Report-only mode first. In this mode the policy evaluates every sign-in and records what it would have done — but takes no action. This lets admins see the impact of a policy before it goes live. Skipping report-only mode and going straight to Enabled is how organisations accidentally lock out their entire user base.
• Policy evaluation order and precedence — multiple CA policies can match a single sign-in. All matching policies are evaluated and their controls are combined. The most restrictive applicable control wins. If any matching policy says Block, the sign-in is blocked regardless of what other policies say. Grant controls are additive — if two policies each require MFA, the user still only gets one MFA prompt.
• Named locations — IP ranges or countries that can be referenced in CA conditions. Define "trusted" locations (the office network, VPN exits) to exclude from MFA requirements, and "untrusted" or "blocked" locations to apply extra controls or deny access entirely.
• The break-glass exclusion — critical — every CA policy must explicitly exclude at least one break-glass Global Admin account. If a misconfigured policy blocks all admin sign-ins and the break-glass account is also excluded, recovery is possible. If the break-glass account is caught by the policy, the tenant may become inaccessible. This is not optional.
• Licence note — Entra ID P1 required — CA policies require Entra ID P1, which is not included in Business Standard. Students will be able to create policies and view the framework, but policies may not evaluate or enforce on Business Standard. Document everything — all policies configured today will be tested and validated when the E5 trial is added in Week 5.

Lab 2-C: Building Conditional Access policies for Lakeview Logistics

Students build four CA policies covering the most important real-world scenarios — MFA for all users, admin protection, legacy auth blocking, and location-based access control. All policies start in Report-only mode. Students then review sign-in logs to observe policy evaluation results.

• Step 1 — Create a named location for trusted networks (10 min)
  Navigate to entra.microsoft.com → Protection → Conditional Access → Named locations → + IP ranges location.
  
  Create: Name: Lakeview Logistics — Trusted Network
  Add the IP range of your lab network (ask your instructor for the public IP, or use whatismyip.com to find it). Check Mark as trusted location. Save.
  
  This location will be used as an exclusion in the MFA policy — users on the trusted network won't be required to MFA on every sign-in.
• Step 2 — Policy 1: Require MFA for all users (15 min)
  Navigate to Protection → Conditional Access → Policies → + New policy.
  
  Configure as follows:

• Step 3 — Policy 2: Protect admin sign-ins (10 min)
  Create a second policy with these settings:

• Step 4 — Policy 3: Block legacy authentication (10 min)
  Create a third policy:

• Step 5 — Policy 4: Block sign-ins from outside Canada (10 min)
  First, create a named location for allowed countries:
  Protection → Conditional Access → Named locations → + Countries location
  Name: Lakeview Logistics — Allowed Countries. Select: Canada. Save.
  
  Then create the policy:

• Step 6 — Review the What If tool and sign-in logs (5 min)
  Navigate to Protection → Conditional Access → What If. Set the user to your Global Admin account, the app to Microsoft Admin Portals, and the IP address to your current IP. Run the What If analysis and review which policies would apply and what action they would take.
  
  Then navigate to Protection → Conditional Access → Sign-in logs. Filter for sign-in events from today. Click into any recent event and review the Conditional Access tab — observe the Report-only evaluation results showing what each policy would have done.

⭐ Bonus: Sign-in risk policy & CA policy audit via PowerShell

Reflection & preview

• Ask: "All four policies are in Report-only mode. What specific thing would you check in the sign-in logs before promoting CA001 to Enabled?" — surface the validation process
• Ask: "CA004 blocks all sign-ins from outside Canada. A Lakeview Logistics employee is travelling to the US for a conference. What happens when they try to sign in, and what do you do?" — surface the operational implications of location-based blocking
• Ask: "Why is excluding the break-glass Global Admin account from every CA policy non-negotiable?" — reinforce the recovery account concept
• Collect exit ticket: explain what report-only mode is, why it exists, and what evidence you would need to see before enabling CA001 in production
• Preview Day 4: CA policies cover access control for regular sign-ins. Day 4 introduces two more identity tools — SSPR for user self-service and PIM for just-in-time privileged access, the gold standard for admin account protection